當 AI 工作坊告一段落，同仁帶著各自完成的微型自動化流程回到部門時，那份成就感很容易感染所有人。

原本月底總要埋首核對款項的財務同仁，終於能讓程式協助整理資料；每週一被通路報表追著跑的營運夥伴，也看見零散檔案在自己的操作下排列整齊。他們眼神發亮，彷彿手裡握著剛出爐的倚天劍。

不過若是再多問一句：

「如果明天，做出這套流程的人沒有來上班呢？」

工作坊教會了同仁如何「拔劍」。接下來的真正考驗，是讓整個團隊也能「接得住」。

一、一張請假單，就能照見流程的脆弱

試想這個極其真實的辦公室場景：

某位營運同仁向部門主管展示了他的新工具：放進檔案、執行程式、核對結果，原本繁瑣耗時的跨系統報表，幾分鐘內就整理完成。主管滿意地點點頭：「太棒了，以後月底這份報表就靠你了。」

幾週後，這位同仁請了兩週婚假。接手的代理同事打開資料夾，螢幕上赫然擺著幾份腳本、一串 AI 對話紀錄，以及兩個分別叫做「最新版」與「最新版修正」的檔案。

「這個按鈕可以直接按嗎？」

「好像要先整理原始檔……」

「整理哪裡？要刪掉哪幾欄？」

「不知道，平常都是他在弄的。」

最後，大家只能嘆口氣，重新打開 Excel，默默回到複製、貼上、逐筆肉眼核對的石器時代。

在軟體工程與組織行為學中，有一個帶著黑色幽默的概念叫做「巴士係數（Bus Factor）」：最少失去多少位掌握關鍵知識的人，專案就會因為嚴重的知識斷層而陷入癱瘓？如果答案是「1」，代表這套流程脆弱得不堪一擊。

同仁通常沒有刻意藏私。他只是習慣了某個欄位要先手動清空、知道哪份檔案才是最後生效的版本，卻忘了把這些「順手的小動作」轉化為系統知識留下來。

工作坊結束後的第一步，就是告別這種脆弱的個人英雄主義，把深藏在個人腦海裡的技術雜技，整理成團隊能夠共讀且接手的韌性流程。

二、把劍放到桌上：從三筆資料開始共讀

想要打破黑盒子，不需要大費周章召開正式的代碼審查會。找一個週五下午的安靜時段，邀請兩三位平時處理相近業務的夥伴坐到螢幕前。

把劍放到桌上，先放三筆測試資料：一筆正常、一筆缺少日期、一筆帶著負數金額。

原作者指著畫面說明：「我的邏輯是：先依案件編號比對金額，缺日期的列進補件清單，負數則另外標記為異常。」

這時，坐在旁邊的資深同事可能立刻提出質疑：「等等，負數在我們業務情境裡也可能是退款，不能全部當成錯誤踢掉吧？」

看，當這個問題浮出水面時，「業務共讀」才算真正開始。

大家一起在螢幕前釐清：哪些差異屬於正常的商業特例？哪些情況必須退件？哪些環節必須保留人工裁決？三筆資料是用來說明邏輯架構；等框架對齊後，再補上邊界值、重複資料與實際遇過的棘手例外。

接著，打開當初的「施工筆記」——也就是備存下來的對話紀錄。讓大家親眼看見 AI 曾經在哪個環節誤解需求，而你又是如何下達限制條件將它引回正軌。此時必須特別提醒夥伴一個非技術人員常有的認知盲點：

Prompt 不是編譯好的 EXE 執行檔，它帶有機率的浮動性。

哪怕下達同一段提示詞，輸出的語氣與結構偶爾也會有些微飄移。大家共讀的目的，是讓團隊看懂「核心邏輯與驗收標準」，學會辨識那個微小的浮動，而不是盲信每一字每一句。

最後，把滑鼠交出去，讓同事在自己的企業核准帳號與環境中，用測試資料親手操作一次。

原作者最熟悉的路，往往藏著最多沒寫下來的轉彎。只有讓別人親自走一次，那些隱藏的轉彎才會浮現出來。

三、把成果裝進食譜，備好兩條走得通的退路

共讀時被問到的每一個問題，都該收斂成一份精簡的操作指南（也就是維運工程中不可或缺的 Runbook）。或許你可以將它稱之為「流程食譜」——一道菜再美味，若說明只寫著「材料適量、火候自行掌握」，接手的人就只能全憑運氣。

一份合格的起步食譜，必須清楚交代四個要素：

原料（Input & Scope）：明確標註資料來源、必要欄位與格式定義，並確認資料來源、日期、套用規則，與採用範本皆正確。

做法（Steps & Prompt）：正式使用的提示詞版本、輔助腳本、操作順序與環境需求。只要內容有所更新，必須用代表性資料重新跑過一次，並在文件頂部留下版本變更紀錄。

驗收（Verification）：輸入與輸出的總筆數是否對齊？關鍵合計金額是否分毫不差？固定提示詞無法保證零出錯，驗收必須具備「獨立於 AI 之外」的客觀核對依據。

退路（Fallback）：何時必須果斷停止？由誰負責拍板切換？改走哪個既有流程？若資料遭誤改該如何復原？

把食譜、腳本、測試資料與必要設定，統一部署在部門受控的共享空間，並清楚註明主責人與第一備援人。

另外你還得試想一下，如果工具突然出問題，暫時無法修復，你還有原來的人工備援途徑嗎？

以前一個人花一下午只能處理一百筆資料，導入自動化後業務規模可能已經暴增到五百筆，因為大家的工作內容跟時間分配都已經改變了。一旦工具停擺、退回人工處理，團隊必須事先達成「降級策略（Graceful Degradation）」的共識：

哪 20% 的關鍵客戶今天非結算不可？

哪 80% 的次要資料可以啟動例外申請、延後處理？

現有的人力最多能支撐幾天？

有一份能看的 SOP 是基本；有一條在極端壓力下真正走得通的降級退路，才叫成熟的架構。

四、原作者把手收起來，備援才算真正驗收

文件寫得再漂亮，沒有經過實戰演練，依然只是一張廢紙。在工作坊結束後的第二週，安排一場不插手的「接手演練」：

原作者站在旁邊，把雙手收進口袋裡；備援夥伴使用自己的電腦、自己的授權帳號，完全依照食譜上的說明，從下載測試資料一路做到最終驗收。

卡在哪裡，就補哪裡。權限不足、套件版本不同、步驟描述含糊，都要在這次演練中徹底解開。

人能獨立接手、資料資產能獨立復原、替代流程在壓力下能承接業務——到了這一步，這套流程才算真正長出了團隊的韌性。

守住下盤，才能邁開大步

當另一位同事能從容獨立操作，原作者緊繃的肩膀會先放鬆下來。

當部門內的分享與備援徹底站穩了下盤，下一個更大的矛盾隨即浮出水面：當我們自己處理得更快了，上游傳來的資料卻依然五花八門，下游又堅持要我們把格式填回古老的報表，這份剛剛長出來的效率，該如何向外延伸？

明天 Day 29，我們將推開部門的大門，聊聊「跨部門的對話與流程接軌」。